Remember those first computers? Mammoth room sized conglomerates filled with glowing vacuum tubes, it took an army of white clad techno-priests working around the clock in their sterile clean rooms to keep them running. And programming them was an exercise best left to your neighborhood nuclear physicist, as it involved actual hardware modifications such as removing a wire and carefully threading it through the machine and plugging it in somewhere else, just to change a byte. If you wanted to make a modest change in the program code it required a staff meeting, if you wanted to replace the operating system (such as it was) an Act of God was needed.
Of course, it got better with time. Programming with wires wasn't any fun, so some potential Nobel Laureate invented the dip switch. This was revolutionary because it also had a hexadecimal keyboard that allowed you to enter numbers directly into the machine. Just flip some dip switches to define an address and carefully type in the value for that byte. And it didn't take too long before the dip switches were themselves replaced by the numeric keyboard, so you could enter both the address and the value easily. At this point the nuclear physicist lost his cushiony job because all that was needed now was the white clad techno-priests in their clean rooms.
Evolution continued on, spawning such remarkable user developments as paper tape, punched cards and keyboards. Soon video terminals began appearing and the white clad priests were laid off and a new professional appeared on the scene, the Programmer. Highly trained, he was able to say things like Opcode or Fortran in meaningful ways during a conversation, and if provoked would unleash a diatribe about such arcane topics as object dumps of core memory. Avoided in normal life, these individuals would bequeath us Cobol and became the unpleasant stereotype for a generation of computer programmers.
By the time serious microcomputers appeared on the scene programming had evolved to the point that almost any engineer or physical scientist could get some computer experience, and computer languages were reaching a high degree of sophistication. Besides low level Assembly language, there was now also high level languages like Fortran, Cobol, Basic, Pascal, Modula II, Forth, Ada, Lisp, Prolog, Logo and C compilers available. And as the hardware advanced, so did the power and flexibility of computer languages.
Today my Amiga computer, with its many megabytes of RAM, hard disk, high speed 68030 processor and graphical user interface bears little resemblance to the computer dinosaurs of the past. Those early technicians very likely never even dared hope for a computer like this, unless it was during some fever inspired dream. And like the hardware itself, the way in which we can create programs has continued to evolve. Even with nearly every significant programming language available on the Amiga new approaches to program creation are still appearing. Some of this evolution in programming originated in the world of modern mainframe systems, but the most interesting aspects are original developments for desktop computers.
For example, with Lattice's C++ package, Amiga C programmers can utilize many Object Oriented Programming (OOP) design and implementation techniques. OOP (and Object Oriented Design, OOD) is mainly concerned with the manipulation of Objects (which are collections of data), and Classes, which are the templates that define the objects. It is a different philosophy from the Top Down programming technique, where the programmer defines the sequence the program flow will occur and builds the code accordingly. In OOP the programmer first fully defines the problem the program must handle. The next step is the definition of the Objects (data) that must be manipulated and the Class (template) best suited to handle the data structures. Once the Class and Objects have been defined, the programmer must determine what operations (verbs) will be performed on or by the Objects.
Object oriented programming has a lot of promise, especially in development situations where each module is created and compiled separately. But it isn't for everyone, and many experienced programmers find it too rigid and complex for their own use. In fact, for many people just about every computer language is too complex for them to use. For all the advances in personal computer power, until recently programming languages and tools have remained fairly complex, and for the average computer user they are just as difficult to understand as the techniques used by the white clad techno-priests of the past.
That appears to be changing. Just as the computers themselves have gotten easier for the masses to use, so to is the act of program creation. Just a few years ago commercial programs began appearing that would allow even non-programmers to create custom database software. To create your own application you merely answered a series of questions which defined the custom application. Then the code writing program would do a lot of writing to the disk, and eventually you would get some very large, usually Basic program that did more or less what you wanted. While not an entirely satisfactory piece of software, it was something anyone could use.
Today we have several new application generating languages for the Amiga. A good example is CanDo, which breaks down the program creation process into the generation of small modules, or cards. The completed application is thought of as a deck of cards. Working this way the programmer is using modern programming practices such as structured programming or object oriented programming without even being aware of it.
Just about anyone who can use a mouse can create a program using CanDo. Most of the program uses requesters to get information about a task. For example, to create a custom window you need only click on the window button, defining the size and number of colors you want by clicking on the Dimension Requester that pops up. Or, you can have it load a previously created picture by selecting the picture from a file requester.
As you can see, using CanDo's high level interface made the act of creating a custom screen and window, as well as loading an IFF image extremely simple. Contrast this user simplicity with the time and effort it would take to write the large number of lines of C code required for the same task.
While CanDO is primarily a requester based system, many of its functions do require you to create a script in order to use them. These scripts are similar to more conventional programs in that they are a set of written instructions executed in a sequential manner. Like Basic, the commands and functions are very high level, but they are not as intuitive for the non-programmer as the other aspects of CanDo are. But for most non-programmers, learning to use the script functions of CanDo will be much easier than trying to learn a language like Basic.
From CanDO we get to Commodore's AmigaVision. Programming in AmigaVision is unlike any other language on the Amiga, as it is entirely graphic in nature. There are no scripts at all, instead you use graphic icons as commands and requesters to input information needed by the program.
An AmigaVision program looks exactly like a flow chart. Each command is placed in position on the flow chart by using the mouse to drag the icon from it's menu and releasing it in the desired position inside the flow window. Once you have acquainted yourself with the icons, it is possible to understand most of the program by just looking at the flow chart. (That reminds me of the old programmers joke that no comments were needed because the code was 'obvious'. AmigaVision comes close to making that true.)
Once positioned in the flow chart, the AmigaVision icon commands must be further defined. By double clicking on the icon, a requester appears with buttons, gadgets and information fields specific to the icon. Using the mouse it is very simple to define the requester, but even here some fields will still require keyboard entry.
What is striking about AmigaVision's approach is it combines two of today's most popular programming techniques. The first is the Top Down approach to structured programming. For many AmigaVision applications it is possible to write the program before you actually go in and define the specifics of the icons. For example, in the program a specific action might trigger a picture to be displayed, while another action would trigger an animation or sound. You don't have to actually define right away what anim, sound or picture will be displayed while defining the overall program flow. These implementation details can be decided on at a later point in the application development.
The other aspect of AmigaVision (and CanDo) is that at least to some degree they can be though of as Object Oriented languages. For example, using our admittedly minimal description of Objects and Classes above, many of the icons could be considered as Class definitions. The Anim requester is the general template for the Class of Object called anims, specifically defining the characteristics required for displaying and playing the anim. Once defined, the requester is an actual anim Object whose fields contain information specific to this Object and what actions it can take.
The point I want to make with all this isn't that these new approaches to programming are for everyone or every project. For most (although not all) commercial software development the conventional languages (C, Modula II, Assembly) are better choices. Some programmers will reject 'cutesy' icon based languages out of hand. Other conventional programmers may have good reason to use one of these new multimedia languages over other methods. And some users will find they can now, finally, write the program they had always wanted but couldn't do before.
It may be some time before these user friendly computer languages reach the point where they are as powerful as today's development systems. And perhaps in the not to distant future we will simply tell the computer what we want it to do and it will write it's own program. It might sound like science fiction today, but with computers getting more powerful all the time, don't think it can't happen. And if you don't believe me, ask the next unemployed, white clad techno-priest you run into.
